E-mail has become an important means of communications. Unfortunately, unsolicited e-mail messages, commonly referred to as SPAM, are cluttering this communications channel. This unsolicited e-mail wastes Internet bandwidth, local area network bandwidth, and storage. This translates into lost productivity, increased computing and increased communication costs. Some of this unsolicited e-mail is also offensive and inappropriate for non-adult audiences.
The spammer collects a list of e-mail address, appends these addresses to their message, and queues these messages on their e-mail server (message transfer agent) 2, in FIG. 1. He then connects their e-mail server to the Internet 1, via in a rogue Internet service provider, a dial-up connection, a digital scriber loop (DSL) connection, or a cable modem connection and sends out their message to gateway message transfer agents 5, associated with each e-mail address. These gateway message transfer agents either stores the message in an e-mail mailbox associated with client 3, or forwards the message to an another message transfer agent (MTA) on the same local area network.
There are four basic approaches to trying to detect junk e-mail messages. One approach used a community set of rules to determine whether or not a message is spam. This approach is used in Razor, an open source Linux solution, and by companies such as CloudMark (based on Razor) and SpamNet. The problem is getting a community of users to agree on a common set of rules.
A second approach uses a set of rule base filters which are periodically updated by the provider and downloaded by the client to determine whether or not a message is spam. The problem is that the set of rules have to be updated and downloaded periodically.
A third approach uses a set of permissions to determine whether or not a message is spam. The problem is that it is impossible for somebody not on user's permission list to send a message to the user.
A fourth approach uses a “whitelist” and a “blacklist” to determine whether or not a message is spam. The problem is that the spammers are constantly changing their return address and declared domain names.
There are three basic ways of implementing these approaches. One implementation approach is in the Message transfer agent. This approach adds some rules to the MTA. The problem is that the MTA program is complicated and inflexible. This limits the kind of rules that can be implemented.
A second implementation approach involves placing the filters between the e-mail client and the Message Transfer Agent. The problem is that some of the information which can be used to help determine whether or not a message is spam is lost or buried.
A third implementation approach involves adding some filters to the e-mail client, Mail User Agent (MUA). The problem is that the e-mail client add-in interface is not an open standard, which leads to compatibility problems.
A problem with these approaches is that they are “reactive.” The spam has already been received by the server and relayed via a local area network to client's computer. The spam message has already consumed the server's Internet bandwidth, local area network bandwidth, and client storage.
Another problem with these approaches is that they are based on the from-address, the subject line, or the message body; all of which can be easily forged or changed.